r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

Could someone kindly start perf after tests, please?

@bors try @rust-timer queue

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

⌛ Trying commit a4c2147044c91d967a24983e6f39e42d1f259c02 with merge d9b995d978da72c2e7147d41e7c4a4a8369ef452...

☀️ Try build successful - checks-actions
Build commit: d9b995d978da72c2e7147d41e7c4a4a8369ef452 (d9b995d978da72c2e7147d41e7c4a4a8369ef452)

Queued d9b995d978da72c2e7147d41e7c4a4a8369ef452 with parent 23f6923, future comparison URL.

Finished benchmarking commit (d9b995d978da72c2e7147d41e7c4a4a8369ef452): comparison url.

Summary: This change led to moderate relevant improvements 🎉 in compiler performance.

• Moderate improvement in instruction counts (up to -2.5% on incr-patched: println builds of regression-31157)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

I updated PR.
I hope, this guesses are better.

May someone start perf again?

@bors try @rust-timer queue

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

⌛ Trying commit ee6b70e746897bdd0ca0c54623ddc9415edc1391 with merge 295c663aa9e8675abae1f4c4781b0e4d1a10b930...

☀️ Try build successful - checks-actions
Build commit: 295c663aa9e8675abae1f4c4781b0e4d1a10b930 (295c663aa9e8675abae1f4c4781b0e4d1a10b930)

Queued 295c663aa9e8675abae1f4c4781b0e4d1a10b930 with parent 3d57c61, future comparison URL.

Finished benchmarking commit (295c663aa9e8675abae1f4c4781b0e4d1a10b930): comparison url.

Summary: This change led to large relevant mixed results 🤷 in compiler performance.

• Large improvement in instruction counts (up to -2.3% on full builds of issue-46449)
• Small regression in instruction counts (up to 2.2% on incr-patched: println builds of regression-31157)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

I am curious, how my PR with added code can lower instruction count? What instruction count means?

Instruction count here means how many instructions were actually executed when compiling a specific crate with specific settings (incremental/non-incremental, check/debug/opt etc.). Lower instruction count usually means faster compile times, so this is actually a good thing!

Since your change only modifies library code, the results seem to hint that it indeed sped up Vec collection, which could translate to nice speedups not only for Rustc compile times, but also for the runtime of all Rust programs!

Oh, that's nice.

However, I wonder why walltime for match-stress-exhaustive_patterns opt increased by 7.46% link.

Also bootstrap times increased too (maybe because there are a lot of code which collects to Vec and I increased amount of code to instantiate in each case?).

Bootstrap is a bit noisy, unless it regresses for +10% or something, it should be fine I think. Wall times are also extremely noisy in general, this one incr-unchanged looks like noise.

JFYI: I wouldn't be able to participate until 15th January. I would return to this PR after that if needed.

⌛ Trying commit 647ac3528a7e4c81c36d24b123d8f32b70e29f55 with merge d499522b3e906fe5c31337590db9d0564b717e42...

☀️ Try build successful - checks-actions
Build commit: d499522b3e906fe5c31337590db9d0564b717e42 (d499522b3e906fe5c31337590db9d0564b717e42)

Queued d499522b3e906fe5c31337590db9d0564b717e42 with parent a34c079, future comparison URL.

Finished benchmarking commit (d499522b3e906fe5c31337590db9d0564b717e42): comparison url.

Summary: This change led to large relevant improvements 🎉 in compiler performance.

• Large improvement in instruction counts (up to -2.9% on full builds of issue-46449 doc)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

If you could summarize the perf results across the runs so that we can make an informed decision as to which variant to use, that would be good.

It seems that last results are best. They don't have any regressions unlike first perf and have better improves than second one.

@bors r+

Thanks -- squashed the commits and approving.

📌 Commit ea570c6 has been approved by Mark-Simulacrum

⌛ Testing commit ea570c6 with merge 74fbbef...

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 74fbbef to master...

Finished benchmarking commit (74fbbef): comparison url.

Summary: This change led to large relevant improvements 🎉 in compiler performance.

• Large improvement in instruction counts (up to -3.0% on full builds of projection-caching doc)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

From testing, this doesn't appear to fix #48994. The lower size hint is still ignored, even though a higher initial capacity is now reserved. Can that issue be reopened?